| 极狐gitlab ci/cd pipeline 效率优化 | 您所在的位置：网站首页 › 持续部署选 极狐Gitlab › 极狐gitlab ci/cd pipeline 效率优化 |
|
极狐gitlab ci/cd pipeline 效率优化
与任何持续集成和持续部署平台一样，速度对于开发人员效率至关重要。 官方文档参考：Pipeline efficiency | GitLab 1. 优化 runner极狐gitlab 提供共享 runner 给所有项目 ci/cd 任务使用。当项目较多时，ci/cd 任务也会增多，这时候运行 pipeline 效率会降低，这是有可以两种优化方式： 1.1 使用 tag 标记 runner在 runner 编辑页面设置 Tags，并且不勾选 Run untagged jobs，这时候此 runner 只运行使用 tag 选择器的 job，这样优化 runner 占用率 示例： stages: - test job1: stage: test script: - echo 'job1' tag: - "docker" 1.2 为项目注册专用 runner点击具体项目，然后在settings -> CI/CD - Expand 中查看项目 runner 注册用的地址和 token，然后再按照官方文档注册 runner：Registering runners | GitLab 即可。 注册完成后，这个 runner 只会运行当前项目的 job。 1.3 使用 k8s 运行 runner将 runner 安装到 Kubernetes 集群中来，并且使用 Kubernetes executor，这样子运行 job 时可以动态的申请集群资源，可以有效避免资源不足的情况。 安装方式参考：使用 K3s 来安装和运行极狐GitLab Runner_哔哩哔哩_bilibili 或者 GitLab Runner Helm Chart | GitLab 2. 使用 cache在运行项目编译时，可能会安装项目依赖，如果每次都从网络安装，会浪费很多时间。这时候可以使用 cache 功能提供缓存，减少依赖安装时间。 前提 runner 开启 cache 功能：Advanced configuration | GitLab 2.1 pip cache示例： image: python:3.9.7 stages: - test variables: PIP_CACHE_DIR: "$CI_PROJECT_DIR/.cache/pip" cache: paths: - .cache/pip/ # 已项目 id 区分 cache，如果不区分，就是全局 cache key: $CI_PROJECT_ID job1: stage: test script: - pip install ansible==2.9.2or image: python:3.9.7 stages: - test cache: paths: - pip-cache # 已项目 id 区分 cache，如果不区分，就是全局 cache key: $CI_PROJECT_ID before_script: - export PIP_CACHE_DIR="pip-cache" - mkdir -p pip-cache job1: stage: test script: - pip install ansible==2.9.2 2.2 nodejs cache示例： variables: NPM_CONFIG_CACHE: npm_cache NPM_CONFIG_REGISTRY: https://registry.npm.taobao.org default: cache: paths: - ${NPM_CONFIG_CACHE} build: stage: build image: node:14-alpine script: - node -v - npm -v - npm ci - npm run build artifacts: name: "build-package" paths: - dist expire_in: 1 day其他语言类似，参考：Caching in GitLab CI/CD | GitLab 3. 安装依赖使用国内源由于国内网络的原因，如果使用默认源的话，安装依赖可能会很慢甚至失败，这时候可以设置国内或者代理解决。 nodejs npm install --registry=https://registry.npm.taobao.orgor yarn config set registry 'https://registry.npm.taobao.org'python pip install --trusted-host mirrors.aliyun.com -i https://mirrors.aliyun.com/pypi/simple -r requirements.txtruby gem sources --remove https://rubygems.org/ gem sources -a https://gems.ruby-china.com gem sources –lgolang go env -w GOPROXY=https://goproxy.cn,direct设置GOPRIVATE来跳过私有库，比如常用的Gitlab或Github，中间使用逗号分隔： go env -w GOPRIVATE=*.gitlab.com,*.github.com 4. docker 优化 4.1 docker 镜像体积优化尽量优化减小 docker 镜像大小 4.1.1 使用Alpine LinuxAlpine Linux是一个基于BusyBox和Musl Libc的Linux发行版，其最大的优势就是小。一个纯的基础Alpine Docker镜像在压缩后仅有2.67MB。并且不少 Docker 官方镜像都有 Alpine 版本，比如：python:3.9.12-alpine3.15、ruby:2.7.5-alpine3.15 等 4.1.2 安装最少依赖如果不是必须，不要安装 vi，wget，curl，ping 等工具。 4.1.3 合并 RUN 指令到一行Dockerfile 中尽量合并多条指令 ... RUN echo 1 \ && echo 2 ... 4.1.4 多阶段构建在Docker 17.05版本以后，新引入了multi-stage builds这一概念，这将会极大地减小镜像大小。 简单来说，multi-stage builds支持我们将Docker镜像的编译分成多个“阶段”。比如常见的软件编译的情况，我们可以将编译阶段单独提出来，软件编译完成后直接将二进制文件拷贝到一个新的基础镜像中，这样做最大的好处就是，第二个镜像不再包含任何编译阶段使用的中间依赖，干干净净明明白白。 具体使用方法：Dockerfile 多阶段构建 - leffss - 博客园 (cnblogs.com) 更多dockerfile最佳实践参考：Best practices for writing Dockerfiles | Docker Documentation 4.2 使用自建 docker hub 镜像仓库默认情况下，docker 使用 Docker Hub 的镜像，网络传输较慢。可以搭建本地 hub 仓库：安装 harbor v2.3.4 - leffss - 博客园 (cnblogs.com) ，加速镜像的 pull 与 push。 pipeline 中使用本地仓库： stages: - build variables: PROJECTNAME: "test" DOCKERHUB: "hub.leffss.com" DOCKERHUBPROJECT: "library" before_script: - docker login ${DOCKERHUB} -u "${DOCKERHUBUSER}" -p "${DOCKERHUBPASS}" after_script: - docker logout ${DOCKERHUB} job1: stage: build script: - docker build --cache-from ${DOCKERHUB}/${DOCKERHUBPROJECT}/${PROJECTNAME}:latest -t ${DOCKERHUB}/${DOCKERHUBPROJECT}/${PROJECTNAME}:${CI_COMMIT_TAG} -t ${DOCKERHUB}/${DOCKERHUBPROJECT}/${PROJECTNAME}:latest . - docker images - docker push ${DOCKERHUB}/${DOCKERHUBPROJECT}/${PROJECTNAME}:${CI_COMMIT_TAG} - docker push ${DOCKERHUB}/${DOCKERHUBPROJECT}/${PROJECTNAME}:latest在有了本地 hub 仓库的情况下，还可以根据 4.1 章节的原则自行打包一些项目编译需要用到的基础镜像，把项目需要用到的基础依赖包或者工具提前打包进去，这样又可以减少 pipeline 安装依赖的时间。 5. 使用 rules 减少不必要作业运行使用 rules 规则跳过某些不必要 job。比如如果只是前端代码改变了，则跳过测试 job。 示例： stages: - build - test build job: stage: build script: - echo 'build job' test job: stage: test script: - echo 'test job' rules: - changes: - backend/* 当 backend 中有变化时运行 test job 也可以使用类似的 only: changes 实现更多 rules 规则参考：Keyword reference for the .gitlab-ci.yml file | GitLab 6. 使用 needs 改变多阶段执行顺序pipeline 中可以定义阶段 stages，如果全局未定义stages, 则按顺序运行 build,test,deploy，job 如果未设置 stage，默认是 test 阶段。 默认情况下：同一阶段的作业并行运行，不同阶段按顺序执行。可以使用 needs 参数改变多阶段执行顺序。 示例： stages: - build - test - deploy build fontend: stage: build script: - echo 'build fontend job' build backend: stage: build script: - echo 'build backend job' test fontend: stage: test script: - echo 'test fontend job' needs: ["build fontend"] test backend: stage: test script: - echo 'test backend job' needs: ["build backend"] deploy fontend: stage: deploy script: - echo 'deploy fontend job' needs: ["test fontend"] deploy backend: stage: deploy script: - echo 'deploy backend job' needs: ["test backend"]使用 needs 参数后：对于前端任务，build fontend 完成后会立即执行下一个阶段的 test fontend，不管 build backend 是否完成。后端的 build backend 任务一样类似。 web 界面中还可以查看 needs 依赖关系。 7. 设置 Job artifacts 合理过期时间pipeline 使用 artifacts 生成制品时，按需设置过期时间，尽量不要过长。 ... pdf: stage: build script: xelatex mycv.tex artifacts: paths: - mycv.pdf expire_in: 1 day ...如果未设置 expire_in 参数，则为全局设置：admin -> settings -> ci/cd |
| CopyRight 2018-2019 实验室设备网 版权所有 |